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PARTS  REQUIREMENTS  AND  COST  MODEL  (PARCOM)  DOCUMENTATION 
PARCOM  USER'S  GUIDE 

CHAPTER  I 

GENERAL  DESCRIPTION 


1-1.  PURPOSE  OF  THE  USER'S  GUIDE.  The  purpose  of  this  user's  guide  is  to 
provide  user  personnel  with  the  information  necessary  to  effectively 
utilize  the  Parts  Requirement  and  Cost  Model  (PARCOM).  PARCOM  is  a 
planning  support  system  for  the  logistics  analyst/planner  which  permits  the 
examination  of  three  critical  logistics  issues: 


•  The  shortfall  of  current  fleet  combat  capability  relative  to 
required  capability  based  on  a  specified  current  spares  inventory. 

•  The  "best"  spares  mix  and  associated  fleet  combat  capability 
achievable  with  a  limited  amount  of  funds  for  add-on  spares. 

•  The  spares  cost  required  to  sustain  a  fleet  flying  program  for  a 
specified  number  of  days  and,  conversely,  the  number  of  days  of 
such  sustainability  achievable  with  a  specified  spares  "budget." 

1-2.  PROJECT  REFERENCES 

a.  Parts  Reqirements  and  Cost  Model  (PARCOM)  Functional  Description, 
CAA-0-84-15,  US  Army  Concepts  Analysis  Agency,  October  1984. 

b.  Aircraft  Spares  Stockage  Methodology  (Aircraft  Spares)  Study, 
CAA-SR-84-12,  US  Army  Concepts  Analysis  Agency,  April  1984. 

c.  Pickard,  W.  C.,  Zellner,  P.  A.,  and  Bailey,  D.  R.,  DOD  Assimilation 
of  US  Air  Force  Methodologies  for  Relating  Logistics  Resources  to  Materiel 
Readiness,  Synergy,  Inc.,  August  1983. 

1-3.  TERMS  AND  ABBREVIATIONS.  The  following  listing  provides  an 
explanation  of  any  terms  or  acronyms  subject  to  interpretation  by  the 


reader: 

acft 

aircraft 

ASL 

authorized  stockage  list 

avail 

availability 

CAA 

US  Army  Concepts  Analysis  Agency 

cum 

cumulative 
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* 

frac 

fraction 

» 

full  sub 

full  substitution  (part  replacement  policy) 

£ 

hr 

hour 

•,* 

ID 

identification 

-  ► 

MAX  FLY 

Maximization  of  Daily  Flying  Hours  (study) 

min 

minimum 

NMC 

not  mission  capable 

i 

NMCS 

not  mission  capable  supply 

no  sub 

no  substitution  (part  replacement  policy) 

.  * 

NRTS 

not  repairable  this  station 

r 

nr 

number 

\V 

NSN 

national  stock  number 

■;’> 

OST 

order  and  ship  time 

r 

PARCOM 

Parts  Requirements  and  Cost  Model 

PLL 

prescribed  load  list 

repl 

replacement 

r 

req 

required 

.■  . 

rqmnt 

requirement(s) 

sub 

substitution 

» 

1-4.  SECURITY  AND  PRIVACY.  All  program  code  and  listings  are  UNCLASSIFIED 
and  require  no  special  security  considerations. 

- 

•>. 

a.  The 
base  used 
output  in 

classification  of  output  reports  depends  on  the  specific  data 
and  the  type  and  labeling  of  generated  output.  All  example 
this  report  is  UNCLASSIFIED. 

i 

b.  The  classification  of  input  files  is  also  a  function  of  the  data 
base  used  and  the  user's  use  of  labeling.  All  example  input  in  this  report 
is  UNCLASSIFIED. 

» 

-a 

1-2 

t. 

*0  -  ] 

■  •'  *«j 
1 
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CHAPTER  2 
SYSTEM  SUMMARY 


2-1.  SYSTEM  APPLICATION 

a.  Requirements  Mode.  PARCOM  provides  information  to  logistics  staff 
officers  on  the  amounts  and  costs  of  cost-effective  mixes  of  aircraft  spare 
parts  required  to  achieve  a  specified  flying  program  under  various: 


•  Cost  constraints. 

f  Initial  inventory  conditions. 

•  Part  replacement  policies. 

•  Aircraft  availability  constraints. 


The  options  for  requirements  cases  are  summarized  in  Table  2-1.  A  row  of 
"X"  entries  denotes  the  simultaneous  assignment  of  conditions  defining  each 
general  case.  The  entry  in  the  last  column  tells  whether  the  combination 
of  options  is  currently  feasible  for  PARCOM  solution. 


Table  2-1.  Key  Attributes  of  Requirements  Cases 


Flying  hour  objective  Aircraft  availability 

objective 


Consecutive 

dally 

achieved 


Cost  objective 


Replacement  policy 


Unconstrained  Constrained  Full 
funds  funds  substitution 


Feasi¬ 

bility 


X 

YES 

NO 

X 

YES 

NO 

• 

X 

YES 

NO 

■  < 
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(1)  Unconstrained  Costs.  With  unconstrained  costs,  a  user  has  un¬ 
limited  funds  but  wishes  to  spend  the  least  amount  for  an  add-on  spare  buy 
which  will  enable  the  fleet  to  achieve  a  specified  goal/objective.  Within 
each  unconstrained  cost  case  the  following  options  apply: 

(a)  Goal /Objective.  The  basic  goal  is  "sparing  to  flying  hours," 
i.e.,  generating  a  parts  mix  which  will  achieve  a  specified  flying  hour 
program  at  least  cost.  An  additional  goal  of  a  minimum  required  (daily) 
aircraft  availability  can  also  be  used.  In  this  context,  aircraft  avail¬ 
ability  =  1  -  NMCS,  where  NMCS  =  the  fraction  of  surviving  aircraft  in  "not 
mission  capable  supply"  status. 

(b)  Initial  Inventory.  Initial  inventory  may  be  set  to  current 
inventory  for  each  item.  PARCOM  will  then  compute  the  least  cost  add-on 
requirement.  The  model,  however,  can  also  generate  a  solution  with  the 
initial  inventory  set  to  zero.  Such  a  solution  is  both  an  add-on  (to  zero) 
as  well  as  a  total  requirements  solution. 

(c)  Parts  Replacement  Policy.  Whether  or  not  a  failed  critical 
part  degrades  aircraft  flying  hour  productivity  depends  on  the  parts 
replacement  policy  used.  Under  a  "no  substitution"  policy,  only  a  spare 
may  replace  a  failed  part.  Under  a  "full  substitution"  policy  a  failed 
part  may  be  replaced  by  either  a  spare  or,  if  a  spare  is  not  readily 
available,  by  a  serviceable  part  removed  from  an  aircraft  which  is  already 
NMC  (not  mission  capable).  A  third  parts  replacement  policy  is  "NMCS  =  0," 
which  has,  as  a  goal,  the  replacement  of  all  failed  parts  with  spares. 
Basically  the  "NMCS  *  0"  policy  is  just  a  "no  substitution"  policy  with  an 
additional  requirement  that  daily  aircraft  availability  be  1.00.  This 
variation  is  of  interest  since  it  represents  the  most  expensive  plausible 
policy.  In  a  sense,  all  else  being  equal,  a  "full  substitution"  policy  is 
associated  with  the  "cheapest"  buy  which  fulfills  the  flying  program,  while 
the  "NMCS  =  0"  policy  is  associated  with  the  "most  expensive"  buy 
("covering"  all  failures  with  spares). 

(2)  Constrained  Costs.  While  the  unconstrained  cost  solution  is  the 
one  that  "best"  meets  the  flying  program,  a  requirements  buy  may  not  be 
affordable  if  funds  are  limited.  With  constrained  costs,  a  user  wishes  to 
apply  limited  funds  to  buy  a  cost-effective  slice  of  the  requirements  best 
buy.  The  associated  options  are: 

(a)  Goal /Objective.  With  a  "no  substitution"  policy  (see  paragraph 
(c)  below),  the  basic  goal  is  to  maximize  the  number  of  "required"  parts 
(given  unconstrained  funds)  which  are  purchased  with  the  constrained 
budget.  Such  a  goal  tends  toward  maximizing  the  fraction  of  the  flying 
program  achievable  with  the  constrained  budget.  Thus,  the  flying  program 
(possibly  in  conjunction  with  aircraft  availability  constraints)  is  a  part 
of  the  goal/objective. 

(b)  Initial  Inventory.  The  basic  constrained  cost  solution  assumes 
initial  inventory  =  current  inventory  and  computes  an  add-on  solution.  As 
an  option,  the  model  also  computes  a  solution  with  the  initial  inventory  = 
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0,  with  the  total  cost  constraint  equal  to  the  value  of  the  current  inven¬ 
tory  plus  the  add-on  cost  constraint.  Such  a  solution  is  predicated  on 
getting  a  refund  for  current  inventory--a  case  of  limited  practical 
interest. 

(c)  Parts  Replacement  Policy.  Only  a  "no  substitution"  parts 
replacement  policy  is  treated  in  constrained  cost  cases.  Resource  limi¬ 
tations  and  methodological  complications  precluded  inclusion  of  a  con¬ 
strained  cost  mode  with  "full  substitution." 

(3)  Treatment  of  Case  Objectives.  As  shown  in  Table  2-1,  the  user 
specifies  a  flying  hour  objective  in  conjunction  with  availability  ob¬ 
jective.  For  each  of  these,  one  of  two  subobjectives  is  determined. 

Details  on  the  nature  of  these  subobjectives  are  discussed  below. 

(a)  Maximizing  Cumulative  Flying  Hours  Achieved.  This  is  the 
standard  subobjective  met  when  running  a  constrained  cost  case.  It  entails 
the  direct  determination  of  the  parts  mix  which  will  yield  the  greatest 
number  of  achieved  flying  hours  for  a  specified  cost  limit.  The  flying 
hours  achieved  will  be  less  than  the  desired  flying  hour  program  if  the 
cost  limit  is  less  than  the  cost  of  the  unconstrained  cost  solution  mix. 

(b)  Maximizing  Consecutive  Days  of  Flying  Hour  Program  Achievement. 

This  subobjective,  as  the  previous  one,  is  only  relevant  to  constrained 
cost  cases.  For  unconstrained  cost  cases,  achieved  flying  hours  will  equal 
programed  flying  hours,  and  consecutive  days  of  flying  hour  program 
achievement  will  equal  the  total  days  programed  for  the  assumed  war.  The 
solution  mix  meeting  this  constrained  cost  objective  is  obtained  through  a 
two-stage  process.  First  the  user  applies  PARCOM  to  generate  an  uncon¬ 
strained  cost  "no  substitution"  solution.  The  output  list  from  that  run 
shows,  for  each  day,  the  cumulative  cost  of  the  add-on  parts  that  would 
have  been  required  if  the  war  were  truncated  at  that  day.  D,  the  last  day 
on  that  list  for  which  the  associated  "no  substitution"  cost  is  less  than 
or  equal  to  the  "cost  limit"  of  the  constrained  cost  case,  is  then  the 
maximum  number  of  consecutive  days  sustainable  at  100  percent  program 
flying  hours  with  "cost  limit"  spares  dollars.  Next,  the  desired  solution 
mix  is  obtained  by  running  PARCOM  again,  in  an  unconstrained  cost  mode, 
with  a  truncated  war  of  D  days  in  length. 

(c)  Minimum  Specified  Daily  Aircraft  Availability.  This  sub¬ 
objective  is  in  addition  to  any  flying  hour  objective  and  is  operative  in 
all  cases.  The  availability  objective  may  increase  the  demand  for  avail¬ 
able  aircraft  beyond  those  required  to  achieve  the  flying  program.  The 
input  availability  constraints  are,  as  described  previously,  used  to  calcu¬ 
late  daily  "allowed  NMCS  aircraft,"  which,  in  turn,  is  used  in  all  case 
calculations. 

(d)  No  Specified  Daily  Aircraft  Availability.  PARCOM  must  always 
read  in  values  for  minimum  daily  aircraft  availability  objectives: 
however,  entering  blank  or  zero  equates  to  not  specifying  an  availability. 
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•  Record  Set  9 

-  IMSEL  must  be  less  than  or  equal  to  5. 

-  The  "part  numbers"  for  IPT(K)  must  be  the  internal  PARCOM 
subscripts  for  the  specified  part  types.  These  are  printed  in 
the  Parts  Input  Data  List  at  the  beginning  of  output  where  the 
entire  part  data  base  is  "echoed"  with  the  "part  number"  ap¬ 
pended  for  those  parts  processed.  Data  on  parts  not  processed 
are  also  printed  in  that  list,  but  no  part  number  is  appended. 
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•  Record  Set  3 

-  CLNCR  is  also  added  to  the  value  of  current  inventory  for 
processed  parts  (with  nonzero  failure  rate)  to  establish  a 
computed  cost  limit  for  the  total  (initial  inventory  =  0) 
requirements  case  with  constrained  cost. 

-  LIMIT  should  normally  be  set  to  4  or  less.  A  high  value  of 
LIMIT  increases  processing  time  for  capability  assessment.  The 
higher  the  value  of  LIMIT,  the  closer  is  the  convergence  of 
"flying  hours  flown"  in  the  capability  assessment  calculation. 
The  closeness  is  printed  in  the  output;  so  the  user  has  a  guide 
for  "trial  and  error"  tests. 


•  Record  Set  4 

-  The  I0PT1  through  I0PT5  options  only  suppress  printing.  Calcu¬ 
lations  are  still  done.  The  I0PT6  option  does  suppress 
calculation  as  well  as  printing. 

-  The  IPRT4  can  save  considerable  processing  time  in  a  run  if  it 
is  set  to  NW.  In  that  instance,  all  computations  are  done 
except  for  the  "cumulative  requirements  through  day  N"  table 
for  "no  substitution."  Note:  IPRT4  should  always  exactly 
divide  into  NW  (number  of  days  in  war). 


•  Record  Set  5 

-  The  NAC(I)  must  be  input  in  the  same  order  as  the  IDAY(I). 
Similar  remarks  apply  to  Record  Sets  6-8. 


•  Record  Set  6 

-  For  I  =  NFHDAY,  NFH(I)  is  the  daily  flying  hours  from  I  DAY ( I ) 
through  NW  (end  of  war).  Similar  remarks  apply  to  Record  Sets 
7-8. 


•  Record  Set  8 

-  "No  availability  constraint"  can  be  modeled  by  having  one 
interval  (NMDAY  =  1)  with  IDAY(l)  =  1,  and  AM(1)  =  0. 
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b.  Figure  2-2  shows  a  sample  scenario  data  base. 


(J.  9 

TEST  NUMBER  1 

9300.  2 

10.  S 
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9 
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500  1000  1SOO  1500 

1 
1 

0. 

?  2 

.10  .09 

2 

1  2 


Figure  2-2.  Scenario  Data  Base 


2-9.  REMARKS  ON  SCENARIO  DATA  BASE.  The  following  remarks  amplify  and 
clarify  the  meaning  and  use  of  several  elements  of  the  Scenario  Data  Base 
defined  in  Table  2-5: 


•  Record  Set  1 

-  ADDOST  was  needed  in  PARCOM  demonstration  runs  only  because  the 
Overview  parts  data  base  used  by  CAA  had  a  zero  entry  for  order 
ship  time.  A  properly  constructed  Overview  parts  data  base 
would  use  ADDOST  =  0. 

-  CONVF  should  be  set  to  a  small  positive  number  less  than  .05. 
Both  CONVF  and  LIMIT  determine  duration  of  capability  assess¬ 
ment  processing  for  constrained  cost.  See  Chapter  3  for  an 
example  application  of  CONVF. 

-  IESS  could  be  set  =  1  for  a  parts  data  base  in  which  all 
"essential  items"  are  coded  1. 
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Table  2-5.  Scenario  Data  Base  Format 
(page  4  of  4  pages) 


Columns 

PARCOM 

name 

Dimension 

Format 

Description 

Record  Set  8  (cont) 

1-80  IDAY(I)  61 

1615 

Initial  day  of  interval  (in  in- 

1-80 

AM(  I ) 

61 

1615 

creasing  order)  requiring  specified 
"minimum  required  aircraft  avail¬ 
ability" 

Daily  "minimum  required  aircraft 

Record  Set  9 

1-5  IMSEL 

1 

15 

availability"  for  each  day  from 
IDAY(I)  through  the  day  before 
IDAY(I+1),  or  through  day  NW 

The  number  of  part  types  for  which 

1-80 

IPT(K) 

5 

1615 

"cumulative  requirement  total  for 
each  day"  will  be  printed  in  the 
Cumulative  Stock  Requirement  List 
for  Selected  Items 

The  "part  numbers"  (from  echoed  Part 

Input  Data  List)  of  the  specified 
(IMSEL)  part  types  to  be  represented 
in  the  Cumulative  Stock  Requirement 
List  for  Selected  Items 


Table  2-5.  Scenario  Data  Base  Format 
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Columns 

PARCOM 

name 

Dimension 

Format 

Description 

Record  Set  5  (cont) 

1-80 

NAC(I) 

61 

1615 

Cumulative  number  of  aircraft  de¬ 
ployed  by  IDAY(I).  These  are  input 
in  the  same  order  as  IDAY(I).  NAC(I) 
applies  from  day  IDAY(I)  through  day 
IDAY(I+1)-1,  or  (for  the  last  interval) 
through  day  NW 

Record  Set  6 

1-5 

NFHDAY 

1 

15 

Number  of  day  intervals  for  which 
daily  program  flying  hours  are 
specified 

1-80 

IDAY(I) 

61 

1615 

Initial  day  of  interval  (in  in¬ 
creasing  order)  for  specified  (by 

NFH(I)  below)  program  flying  hours 

1-80 

NFH(I) 

61 

1615 

daily  program  flying  hours  for 

each  day  from  IDAY(I)  through  the 

day  before  IDAY(I+1),  or  through  day  NW. 

Record  Set  7 

1-5 

NLDAY 

1 

15 

Number  of  day  intervals  for  which 
daily  aircraft  attrition  losses 
are  specified 

1-80 

IDAY(I) 

61 

1615 

Initial  day  of  interval  (in  in¬ 
creasing  order)  for  specified 
daily  aircraft  losses 

1-80 

ZLOSS(I) 

61 

16F5.1 

Daily  aircraft  losses  for  each  day 
from  IDAY(I)  through  the  day 
before  IDAY(I+1) 

Record  Set  8 

1-5 

NMD  AY 

1 

15 

Number  of  day  intervals  for  which  a 

"minimum  required  aircraft  avail¬ 
ability"  is  specified 


2-13 


Table  2-5.  Scenario  Data  Base  Format 
(page  2  of  4  pages) 


Columns 

PARCOM 

name 

Dimension 

Format 

Description 

Record  Set  4  (cont) 

26-30 

I0PT2 

1 

15 

Option  (0  =  omit,  1  =  do)  to  print 
requirements  list  for  uncon¬ 
strained  cost  residual  requirements 
solution 

31-35 

I0PT3 

1 

15 

Option  (0  =  omit,  1  =  do)  to  print 
requirements  list  for  constrained 
cost  "total  buy"  solution  (see 

Remarks) 

36-40 

I0PT4 

1 

15 

Option  (0  =  omit,  1  =  do)  to  print 
requirements  list  for  constrained 
cost  add-on  buy  solution 

41-45 

I0PT5 

1 

15 

Option  (0  *  omit,  1  =  do)  to  print 
total  cumulative  daily  require¬ 
ments  for  selected  items  (see 

Remarks) 

46-50 

I0PT6 

1 

15 

Option  (0  =  omit,  1  =  do)  to  do  the 
constrained  cost  case 

61-65 

IPRT 

1 

15 

Option  (0  =  omit,  1  =  do)  to  print 
the  scenario  input  data  summary 

66-70 

IPRT4 

1 

15 

Interval  (days)  at  which  "cumulative 
requirements  through  day  N"  are  cal¬ 
culated  for  the  "no  sub"  unconstrained 
cost  requirement  cases 

Record  Set  5 

1-5 

NACDEP 

1 

15 

Number  of  day  intervals  (see  IDAY(I) 
below)  for  which  aircraft  deployments 
are  specified 

1-80 

IDAY(I) 

61 

1615 

Initial  day  of  interval  (in  in- 

creasing  order)  for  specified  (by 
NAC ( I )  below)  aircraft  deployment 


Table  2-5.  Scenario  Data  Base  Format 
(page  1  of  4  pages) 
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Columns 

PARCOM 

name 

Dimension 

Format 

Description 

Record  Set  1 

1-5 

ADDOST 

1 

F5.2 

Offset  (days)  added  to  order  ship 
time  read  from  parts  data  base 

6-10 

CONVF 

1 

F5.2 

Convergence  goal  for  "flying 
hours  flown"  calculation  during 
capability  assessment  (see  Remarks) 

11-15 

IESS 

1 

15 

Maximum  essentiality  code  for  a 
part  type  to  be  processed 

Record  Set  2 

2-17 

CASE 

1 

A16 

Case  (run)  identification 

Record  Set  3 

2-15 

CLNCR 

1 

F14.0 

Add-on  cost  limit  (dollars)  for 
constrained  cost  cases 

16-20 

LIMIT 

1 

15 

Maximum  number  of  iterations  of 

"flying  hours  flown"  calculations 
during  capability  assessment  (see 
Remarks) 


Record  Set  4 

2-10 

FHM 

1 

F9.1 

Maximum  flying  hours/aircraft/day 

11-15 

NW 

1 

15 

Number  of  days  in  war  (length  of 
scenario) 

21-25 

I0PT1 

1 

15 

Option  (0  =  omit,  1  =  do)  to  print 
requirements  lists  for  uncon¬ 
strained  cost  total  requirements 
solution 

.-v 


Table  2-4.  Parts  Data  Record  Format 


Record 

number 

PARCOM 

name 

Columns 
in  field 

Format 

Description 

1 

11 

3-17 

A15 

National  stock  number  of  part 

12 

18-26 

F9.0 

100  *  unit  cost  (dollars)  of  part 

13 

32-34 

F3.0 

Order  ship  time  (days)  for  part 
(=  0  for  all  parts  in  example  data) 

Z4 

35-39 

F5.0 

1,000,000  *  failure  rate  (failures 
per  flying  hour)  for  part 

Z5 

40-42 

F3.0 

NRTS  (not  repairable  this  station) 
percentage,  i.e.,  percent  of  fail¬ 
ures  sent  to  depot  for  repair 

Z6 

43-45 

F3.0 

Retail  repair  time  (days)  for  part 

17 

46-48 

F3.0 

Depot  repair  time  (days)  for  part 

18 

49-51 

F3.0 

Retail  condemnation  rate  (percent 
scrapped  at  retail  repair) 

19 

52-54 

F3.0 

Depot  condemnation  rate  (percent 
scrapped  at  depot  repair) 

IES 

55 

11 

Essentiality  code  of  part  (1  =  most 
essential ) 

I  NIT 

66-70 

15 

Initial  inventory  (wholesale  +  retail) 
for  part 

5 

IQPA 

1-2 

12 

Quantity  per  application,  i.e.,  num¬ 
ber  of  parts  installed  per  aircraft 

6 

ADSC 

1-16 

A16 

Description  of  part 

2-8.  SCENARIO  DATA  BASE  FORMAT 

a.  The  scenario  data  base  read  by  PARCOM  consists  of  9  sets  of  card 
image  records,  as  shown  in  Table  2-5,  which  summarize  names,  formats,  and 
descriptions.  Record  sets  1  through  4  always  have  exactly  1  card.  Record 
set  9  always  has  2  cards.  The  length  of  record  sets  5-8  depends  on  user 
specification  as  noted  below.  All  record  sets  must  be  present.  Aircraft 
availability  constraints  are  "omitted"  by  setting  AM  (I)  =  0  in  Record  Set 
8  for  all  days.  Remarks  on  Table  2-5  are  given  after  the  table  in  order  of 
input. 
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2-7.  PARTS  DATA  BASE  FORMAT.  The  parts  data  base  read  by  PARCOM  consists 
of  3  file  header  records,  which  are  skipped,  followed  by  a  series  of  sets 
of  12  records,  each  set  being  associated  with  data  for  a  single  part  type. 
PARCOM  reads  from  only  3  of  the  12  records  in  each  set,  the  first,  fifth, 
and  sixth  records.  The  rest  are  skipped.  The  program  could  be  altered  to 
read  a  compressed  parts  data  package  which  could  be  constructed  by  pre¬ 
processing  an  Overview  parts  data  base  to  "select  out"  the  elements  used  by 
PARCOM.  Table  2-4  gives  the  names,  as  used  by  the  PARCOM  READ  statement, 
and  formats  of  the  parts  data  elements  input  for  each  part  type.  "Record 
number"  in  the  table  refers  to  the  ordinal  position  of  a  data  record  within 
the  12-record  block  for  a  part  type.  "Columns  in  field"  refers  to  the 
character  positions,  within  a  record,  occupied  by  the  tabulated  data  ele¬ 
ment.  "Format"  refers  to  the  FORTRAN  language  format  specification  cur¬ 
rently  used.  "Description"  is  a  summary  definition  of  the  data  element. 
Note  that  some  of  these  input  data  are  scaled  (multiplied  by  a  constant 
factor).  PARCOM  also  converts  all  percent  rates  to  fractions. 


a  Figure  2-1  shows  a  sample  parts  data  base  containing  only  two  part 
types . 
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Figure  2-1.  Parts  Data  Base 


b.  All  data  read  in  are  screened  for  processing.  Only  parts  with 
nonzero  failure  rates  and  with  specified  essentiality  are  processed  and 
assigned  part  numbers  for  internal  PARCOM  reference.  Nonprocessed  parts 
data  is  "echoed"  (printed)  but  is  thereafter  ignored.  All  data  elements 
described  in  Table  2-4  are  associated,  via  a  subscripted  array,  with  the 
"part  number"  of  their  associated  part  type.  Currently,  the  PARCOM  program 
limits  allow  up  to  300  part  types  to  be  processed.  By  "initial  inventory" 
is  meant  total  spares  including  that  in  ASLs/PLLs  not  deployed.  Since 
there  are  no  explicit  ASL/PLL  "deployments"  in  PARCOM,  all  spares  are 
"front  loaded”,  i.e.,  made  available  at  day  1.  "Total  spares"  includes  the 
sum  of  the  following  stocks:  war  reserve,  depot  stocks,  stocks  in  units, 
stockpiled  stocks  for  units,  and  stocks  in  pipeline. 


2-9 


A. 

V- 


-*»  -v  -*«  ^ *»*  *.'-  •■‘lJ 


CAA-D-84-10 


Table  2-3.  Data  Elements  for  the  Scenario  Data  Base 

Scenario  Specification  Data 

•  Case  identifier 

•  Length  of  war 

•  Flying  program 

a  Aircraft  deployment  schedule 

•  Aircraft  losses 
Scenario  Constraint  Data 

•  Add-on  cost  limit  (for  constrained  cost) 

•  Aircraft  availability  constraints  (minimum  daily  availability) 

•  Maximum  flying  hours  per  aircraft  per  day 
Additional  Parts  Data 

•  Order  ship  time  offset 

•  Maximum  essentiality  code  for  part  to  be  processed 

Print/Calculate  Options 

•  Options  on  printing  of  total  and  of  residual  requirements  lists 
for  unconstrained  and  for  constrained  cost  cases 

•  Option  on  printing  daily  cumulative  total  requirements  for 
selected  items  specified  by  user 

•  Option  to  omit  all  constrained  cost  calculations 

a  Option  to  limit  the  "cumulative  requirements  by  day"  calculations 
for  "no  substitution"  to  user-specified  intervals 

•  Option  to  print  a  scenario  input  data  summary 

Tuning  Parameters 

•  Desired  closeness  of  "flying  hours  flown"  convergence  during 
capability  assessment 

•  Maximum  number  of  iterations  used  to  calculate  "flying  hours  flown 
during  capability  assessment 


Table  2-2.  Data  Elements  for  Each  Part  Type  in  the  Parts  Data  Base 


(1)  National  Stock  Number  (NSN) 

(2)  Unit  cost 

(3)  Retail  repair  time 

(4)  Depot  repair  time 

(5)  Order  and  ship  time 

(6)  Failure  rate 

(7)  Retail  NRTS  rate 

(8)  Retail  condemnation  percentage 

(9)  Depot  condemnation  percentage 

(10)  Item  Essentiality  Code 

(11)  Quantity  per  application 

(12)  Initial  inventory 


b.  The  rest  of  the  PARCOM  input  data  base  is  denoted  by  "the  scenario 
data  base"  and  consists  of  scenario  specification  data,  scenario  constraint 
data,  additional  (to  parts  data  base)  parts  data,  and  print/calculate 
options.  These  are  summarized  in  Table  2-3.  These  records  are  all  card 
image.  During  PARCOM  execution  the  parts  data  base  is  read  between  the 
first  and  last  scenario  data  base  records.  Therefore,  the  two  afore¬ 
mentioned  data  bases  should  always  be  read  on  separate  logical  units  if,  as 
is  now  the  case,  the  two  data  bases  are  separately  formatted  and  con¬ 
structed. 
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scenario  data,  for  the  current  maximum  capacity  of  300  part  types  in  a 
(maximum)  120-day  scenario,  consists  of  approximately  40-120  records 
depending  on  the  day-to-day  variation  in  specified  aircraft  deployments, 
flying  program,  and  availability  goals. 

b.  Output.  The  parts  data  input  is  "echoed,"  i.e.,  printed  in  an 
output  list.  A  variety  of  reports  on  spare  requirements  (costs  and 
amounts,  total  and  by  part  type),  and  resulting  capability  (aircraft 
availability,  fraction  flying  goal  achieved,  and  flying  hours  per  aircraft 
per  day)  are  printed.  For  each  demonstration  case  at  maximum  capacity,  the 
volume  of  printed  output  is  60  pages. 

c.  Limitations.  The  model  is  currently  designed  for,  at  most,  300  part 
types  processed  over,  at  most,  a  120-day  scenario.  However,  these  limits 
may  be  increased  by  altering  the  DIMENSION  and  COMMON  statements  of  the 
FORTRAN  code,  insofar  as  available  computer  memory  allows.  Further 
extension  of  capacity  can  be  achieved  by  "splitting"  PARCOM  into  several 
submodels,  each  of  which  processes  only  a  specific  problem,  from  the  set 
currently  treated  in  a  single  "run"  of  a  single  model.  With  its  current 
limits,  PARCOM  uses  33K  of  memory  on  the  Sperry  1100/82  computer  at  CAA. 

d.  Processing  Time.  The  central  processing  time  required  for  a  PARCOM 
execution  depends  on  the  scenario  length  and  the  number  of  part  types 
processed,  as  well  as  the  types  of  problems  processed.  A  complete  PARCOM 
execution  with  the  above  limits  consumes  approximately  220  central  proces¬ 
sing  seconds  on  the  CAA  computer. 

e.  Flexibility.  PARCOM  was  designed  to  accommodate  numbers  of  part 
types  and  scenario  lengths  beyond  the  programed  limits  by  allowing  the  user 
to  modify  only  the  DIMENSION  and  COMMON  statement  limits  in  the  FORTRAN 
code.  In  doing  so,  the  user  must  consider  both  his/her  computer  memory 
limits  and  the  increased  processing  time  required  to  run  larger  problems. 
During  the  PARCOM  documentation/transfer  phase,  CAA  will  investigate  ways 
of  representing  "partial  substitution"  with  the  basic  PARCOM  methodology. 

2-6.  DATA  BASE 


a.  The  major  portion,  in  terms  of  quantity  of  records,  of  the  PARCOM 
input  data  base  is  from  the  parts  data  base  designed  for  the  Overview 
Model.  PARCOM  uses  the  data  elements  shown  in  Table  2-2.  The  Overview 
parts  data  base  is  described  in  a  SYNERGY,  Inc.  report  (see  reference  in 
paragraph  l-2b).  Only  a  portion  of  the  information  in  the  Overview  parts 
data  base  is  read  and  used  by  PARCOM.  Since  the  parts  data  base  has 
records  of  102  characters  in  length,  it  is  not  read  as  card  image  (80 
characters  per  record),  and  therefore,  must  be  read  from  a  peripheral 
storage  device  (tape  or  disc). 
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capability  with  which  the  "achievable  capability"  generated  from  a 
requirements  solution  mix  might  be  compared. 

2-2.  SYSTEM  OPERATION 

a.  PARCOM  is  designed  to  operate  from  card  image  input  constructed  by 
the  user,  along  with  a  parts  data  bai  in  the  format  used  by  the  Overview 
Model  in  the  US  Army  Concepts  Analysis  Agency  (CAA)  Maximization  of  Flying 
Hours  (MAX  FLY)  Study.  A  peripheral  storage  device  (tape  or  disc)  is  used 
to  store  the  parts  data  base,  since  it  is  not  a  card-image  format. 

b.  PARCOM  output  consists  almost  entirely  of  printed  files.  The  type 
and  quantity  of  output  can  be  controlled  to  a  degree  by.  user-specified 
input  options. 

2-3.  SYSTEM  CONFIGURATION.  The  current  PARCOM  version  was  developed  for 
the  Sperry  1100/82  Multi-Processing  System  at  CAA.  The  model  is  coded  in 
FORTRAN. 

2-4.  SYSTEM  ORGANIZATION.  PARCOM  is  implemented  as  a  single  processor 
which: 

•  Reads  part  type  data/characteristics  from  a  peripheral  storage 
device. 

•  Reads  card  image  scenario  data  supplementary  to  the  parts  data. 

The  scenario  data  also  specify  the  goal /objective  for  the  solution 
requirement  mix(es). 

•  Generates  cost-effective  requirements  solution  mixes  (costs  and 
composition)  of  spares  based  on  the  specified  goals. 

t  Generates  achievable  combat  capability  (readiness,  flying  hours) 
reflected  in  the  solution  spares  mixes. 

As  noted  earlier,  a  single  PARCOM  execution  can  generate  requirements 
solution  mixes  for  a  variety  of  initial  inventory  conditions,  parts 
replacement  policies,  and  cost  constraints. 

2-5.  PERFORMANCE 

a.  Input.  The  parts  data  base  for  PARCOM  is  in  the  format  used  by  the 
Overview  Model,  as  modified  for  CAA.  The  data  base  consists  of  12  records 
for  each  part  type,  with  each  record  being  up  to  102  characters  in  length. 
For  the  current  maximum  capacity  of  300  part  types,  the  Overview/PARCOM 
parts  data  base  would  have  3,603  records  (3  "label"  records  begin  the  data 
base).  However,  since  only  3  records  are  read  by  PARCOM  from  each  "part 
type"  set  of  12,  only  900  of  tne  3,603  records  are  used.  The  card  image 


2-5 


(4)  Capability  Value  of  Requirements  Mixes.  After  a  requirement 
solution  mix  is  computed,  PARCOM  will  also  generate  a  record  of  daily 
achievable  fleet  flying  capability  implied  by  use  of  that  solution  mix. 
The  capability  assessment  measures  are: 

•  Daily  achievable  aircraft  availability. 

•  Daily  achievable  fraction  of  flying  program  completed. 

•  Daily  achievable  flying  hours  per  available  aircraft  per  day. 


Overall  average  (over  the  scenario  length)  values  of  these  measures  are 
also  computed.  In  the  requirements  mode,  PARCOM  capability  assessment  re¬ 
sults  superficially  show  the  logistics  planner  cases  in  which  the  costs  of 
correcting  capability  shortfalls  are  based  only  on  filling  inventory  short¬ 
falls  (i.e.,  by  buying  spares).  However,  the  results  may  also  suggest  the 
need  to  examine  the  cost  effectiveness  of  other  ways  to  meet  the  flying 
program  objective.  For  example,  intensive  management  or  improved  efficien¬ 
cy  in  repair  and  processing  cycles  might  reduce  requirements  by  shortening 
the  length  of  the  logistics  pipeline.  In  addition,  product  improvement 
programs  might  reduce  requirements  by  lowering  failure  rates.  Applied  with 
the  constrained  cost  option,  PARCOM  could  be  used  to  compare  improvements 
in  flying  hour  program  capability  from  applying  a  fixed  number  of  dollars, 
C,  to  "pipeline/failure  rate  improvement"  with  improvements  from  "buying 
spares."  The  capability  with  a  qualitatively  improved  current  inventory 
can  be  compared  to  the  capability  resulting  from  the  constrained  cost  so¬ 
lution  obtained  by  using  the  C  dollars  to  efficiently  "buy  spares." 

b.  Capability  Assessment  Mode.  While  designed  primarily  as  a  require¬ 
ments  assessment  model,  PARCOM  can  also  assess  the  capability  of  an  air¬ 
craft  fleet  with  a  specified  (e.g.,  current)  spare  inventory  to  meet  a 
flying  hour  objective.  However,  the  nature  of  the  feasible  capability 
assessment  depends  on  the  part  replacement  policy  treated.  Given  a  speci¬ 
fied  wartime  flying  hour  program  objective,  PARCOM  can  assess  the  number  of 
consecutive  days  of  100  percent  flying  program  achievement  and  the  fraction 
of  the  cumulative  program  hours  achievable  with  any  starting  inventory  and 
a  "no  substitution"  replacement  policy.  It  can  also  assess  consecutive 
days  of  100  percent  achievement  for  a  "full  substitution"  policy  but  not 
the  fraction  of  the  program  achieved.  In  order  to  assess  consecutive  days 
of  100  percent  achievement  in  both  cases,  the  user  operates  PARCOM  in  any 
standard  run  with  input-specified  current  inventory.  One  output  from  that 
run  gives  cumulative,  by  day  of  war,  cost  of  the  residual  (add-on) 
requirement  for  a  scenario  truncated  at  the  specified  day.  The  latest 
(last)  day  for  which  there  is  a  zero  add-on  requirement  cost  is  the  last 
day  of  the  period  of  sustainability  with  current  inventory.  The  capability 
associated  with  current  inventory  is  assessed  by  treating  cur-rent 
conditions  as  a  special  case  of  a  constrained  cost  capability  assess-ment 
with  an  add-on  limit  of  zero  dollars.  The  primary  use  of  the  capability 
assessment  mode  would  probably  be  to  establish  a  baseline  current 
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CHAPTER  3 
MODEL  OUTPUT 


3-1.  INPUT  CONSTRAINTS.  The  user  can  limit  the  amount  of  output  produced 
by  the  values  assigned  to  the  inputs  I0PT1,  I0PT2,  I0PT3,  I0PT4,  I0PT5, 
I0PT6,  and  IPRT4  as  described  in  Table  2-4.  In  addition,  any  case  can  be 
truncated  by  setting  input  NW  (number  of  days  in  war)  to  a  suitably  low 
value. 


3-2.  SCOPE  OF  CASES  PROCESSED 

a.  Cases  Processed.  Figure  3-1  shows  the  eight  cases  processed  in  a 
single  PARCOM  run.  The  subdivisions  represent  parametric  variations  in: 

(1)  Cost  constraints  -  with  and  without. 

(2)  Initial  inventory  of  parts  -  zero  or  as  selected  (usually  current). 

(3)  Parts  replacement  policy  -  "full  substitution,"  "no  substitu¬ 
tion,"  or  "NMCS  =0." 

Entries  shown  as  "XXX"  indicate  user-defined  input  values.  Figure  3-1 
graphically  represents  a  "nested  umbrella"  of  conditions  defining  each  of 
the  eight  cases  identified,  i.e.,  all  blocks  above  Case  ID  in  the  chart 
state  the  defining  conditions  of  that  case.  These  are  also  implicit  in  the 
Case  ID,  interpreted  as  follows: 


First  character  -  scenario:  A. 


Second  character  -  cost  constraints: 

U  =  unconstrained  or  C  =  constrained. 


Third  character  -  full  or  add-on  requirements: 
T  =  full  (total)  requirements  or  R  =  add-on 
(residual)  requirements. 


Fourth  character  -  part  replacement  policy: 

1  =  full  substitution,  2  =  no  substitution,  or 
3  =  (NMCS  =  0). 


3- 
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Note  that  the  "full  requirements"  case  is  equivalent  to  initial  inventory  = 
0,  while  the  "add-on  requirements"  case  is  equivalent  to  initial  inventory 
=  current  inventory  (or  as  otherwise  entered).  Using  this  notation,  AUR2 
represents  the  case:  Scenario  A,  unconstrained  costs,  residual  (add-on) 
requirements,  and  a  "no  substitution"  parts  replacement  policy. 


Case 

stratification 

for  any 

chosen 

scenario 

Scenario  A 

Acft  availability  constraints  (.XXX...) 

Unconstrained 

Constrained  cost 

Added-buy  11m1t-$XXX 

Initial 
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Initial 
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Part  1  •  XXX 
Part  2  •  XXX 

Initial 

Inventory 

•0 

Initial 
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Part  1  •  XXX 
Part  2  •  XXX 

Full  rqmts 

Add-on  rqmts 

Full  rqmts 

Add-on  rqmts 
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HQ 

No 

sub 

repl 

policy 

NMCS 

-0 

repl 

policy 

Full 

sub 

repl 

policy 

II 

NMCS 

-0 
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policy 
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sub 

repl 

policy 

n 

NMCS 

-0 

repl 

policy 

Ifl 

US 

9 
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•0 

repl 
pol Icy 

Case  ID 

AUT  1 

AUT  2 

AUT  3 

n 

AUR  2 

AUR  3 

ACT  1 

ACT  2 

ACT  3 

ACR  1 

ACR  2 

ACR  3 

Total  rqmt 

■ 

■ 

■ 

111 

11 

11 

■ 

■ 

n 
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’ 

Pesidual  rqmt 
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III 
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■ 
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Cum  cost  by  day 
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X 
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X 

X 

X 

X 
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X 

Cum  req  by  day 
(selected  parts) 

X 

X 

X 

X 

X 

X 

Dally  AC  avail 

■ 

■ 

■ 

■ 

■ 

X 

■ 

a 

■ 

■ 

B 

Oally  fly  hr  fracb 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

a 

■ 

■ 

a 

a 

Produced  whenever  no-substltutlon  policy  with  an  availability  goal  »  1.00  Is  processed. 

^The  dally  flying  hour  fraction  *  1.00  for  all  days  If  the  unconstrained  cost  solution  requirement  Is 
stocked. 


Figure  3-1.  Type  Outputs  Produced  for  Each  Case  Within  a 

PARCOM  Scenario 
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b.  Summary  of  Output.  Figure  3-1  also  shows  the  available  output  pro¬ 
duced  for  each  case  generated  within  a  PARCOM  scenario.  An  "X"  in  the 
matrix  indicates  availability  of  the  type  output,  described  in  the  left 
margin,  for  the  case  with  the  "Case  ID"  shown  above  the  "X".  The  absence 
of  an  "X"  indicates  unavailabil ity.  Shaded  boxes  are  for  inapplicable 
cases.  A  brief  description  of  each  type  output  is  given  below.  A  complete 
descriptive  listing  of  PARCOM  output  tables,  with  samples,  is  given  in  the 
next  major  paragraph. 

(1)  Total  Requirement.  Total  (initial  inventory  =  0)  least-cost 
parts  required  to  achieve  the  flying  program  (unconstrained  dollars),  or 
total  "best"  parts  mix  purchasable  (constrained  dollars). 

(2)  Residual  Requirement.  The  least-cost  add-on  buy,  to  initial  in¬ 
ventory,  which  will  achieve  the  flying  program  (unconstrained  dollars),  or 
the  "best"  add-on  buy  to  initial  inventory  (constrained  dollars). 

(3)  Cumulative  Cost  by  Day.  For  each  Day  N,  the  total  cost  of  the 
parts  requirement  to  sustain  the  scenario  flying  program  through  Day  N 
only,  i.e.,  it  is  the  requirement  for  a  truncated  scenario  of  N  days  in 
length. 

(4)  Cumulative  Requirement  by  Day.  For  selected  items  for  each  Day 
N,  the  cumulative  total  (initial  inventory  =  0)  requirement  needed  for  the 
flying  program  to  be  sustained  through  N  days. 

(5)  Daily  Aircraft  Available.  For  each  day  of  the  full  scenario,  the 
fraction  of  surviving  aircraft  which  are  not  NMCS,  assuming  that  the 
initial  spare  inventory  is  set  equal  to  the  computed  parts  requirement. 

(6)  Daily  Flying  Hour  Fraction.  For  each  day  of  the  full  scenario, 
the  fraction  of  the  fleet  flying  program  which  can  be  achieved  assuming 
that  the  initial  spare  inventory  is  set  equal  to  the  computed  parts 
requirement. 

(7)  Daily  Flying  Hours  per  Available  Aircraft  per  Day.  For  each  day 
of  the  full  scenario,  the  maximum  achievable  program  flying  hours  per  air¬ 
craft  assuming  that  the  initial  spare  inventory  is  set  equal  to  the  com¬ 
puted  parts  requirement. 

3-3.  SAMPLE  OUTPUTS.  A  complete  list  of  standard  outputs  is  presented 
below  in  the  sequence  of  output.  Figures  of  sample  outputs  and  descriptive 
explanations  are  given.  For  convenience,  the  sample  outputs  are  restricted 
to  a  case  involving  two  part  types  over  a  5-day  war.  The  order  of  outputs 
is: 


-  %  %  • 
•  j>  *  •  *  * 


3-3 


a.  Parts  Input  Data  List  (Figure  3-2).  The  raw  parts  data  is  "echoed" 
in  labeled  form.  The  order  of  parts  is  as  input.  The  entries  under  the 
PART  heading  are  the  "part  numbers"  which  are  cross-referenced  in  other 
lists.  COST  denotes  unit  cost  of  the  part.  OST  denotes  the  order/ship 
time  in  days.  FAIL  RT  denotes  failure  rate  in  failures  per  flying  hour. 
NRTS  gives  the  "not  repairable  this  station"  fraction.  BCY  denotes  the 
base  repair  time  (in  days).  OCY  denotes  the  depot  cycle  time  in  days, 
i.e.,  the  time  from  removal  until  return  from  depot  repair.  It  is  the  sum 
of  the  depot  repair  time  and  2  x  OST.  DRT  denotes  depot  repair  time.  BCON 
denotes  the  fraction  of  failed  parts  which  are  condemned  (scrapped)  at 
retail  repair.  DCON  denotes  the  fraction  of  failed  parts  sent  to  depot 
repair  and  subsequently  condemned  at  that  level  of  repair.  QPA  denotes  the 
quantity  per  application  for  the  part,  i.e.,  the  number  of  units  of  that 
part  type  installed  per  operational  aircraft.  ESS  denotes  the  essentiality 
code  of  the  part.  While  all  part  data  is  "echoed"  in  this  list,  only  those 
parts  with  nonzero  failure  rates  and  with  essentiality  code  less  than  or 
equal  to  a  user-specified  level  (IESS)  are  assigned  part  numbers.  Listed 
part  data  not  assigned  a  part  number  are  not  subsequently  processed.  After 
the  last  item  of  the  parts  list,  the  total  number  of  input  part  types 
(TOTAL  NR  PARTS)  is  given  along  with  the  number  of  these  part  types  to  be 
processed  by  PARCOM  (NR  USED).  The  1NIT  STK  column  echoes  the  initial 
stock  (INIT)  entry  in  the  parts  data  base.  It  reflects  total  spare  assets 
(see  para  2-7b. 


IIEHS  RAN*  OROERED  IN  NORMAL  INPUT  ORFL* 
P*»l  MSN  DESCRIPTION 

■  10DSQOTNA96QT  frrnr,  ... 

7  .l5?S99J*»,S*s  ?o"" su-s  u 


TOTAL  NR  PARIS!  S' 


7omh  Gun 
NR  USED!  2 


COST  9SI  PAIL  R!  NATS  ACT  DCT  JR I  »CBN  DCON  SPA  ESS  INIT  SIN 

A:  : 


WO.  i.  .080000  won  o. 
SO.  0*  .020000  .00  3. 


1: 


.03  1 «  I 
•  00  t  •  $ 


?S0 

10 


Figure  3-2.  Part  Input  Data  List 


b.  Input-ordered  Cost/Stockage  List  (Figure  3-3).  This  list  shows  the 
unit  cost  and  initial  inventory  for  each  part  processed.  Parts  are  in  order 
of  input.  Part  numbers  shown  are  defined  as  in  paragraph  3-a  above.  The 
rank  heading  is  redundant  here,  but  is  subsequently  used  in  presenting  this 
data  ordered  by  part  unit  cost.  The  part  numbers  are  cross-referenced  with 
those  in  the  Part  Input  Data  List. 


CASE-TEST  NUMBER  1 


ITEMS  RAMM  OSOEREO  IN  NORM *1.  INPUT  o«0£R 

RANK  PART  MSN  DESCRIPTION 


COST  INI!  ST* 


1 

2 


1 

2 


188 


SOOJ^BRfcnT 
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FEEDER  AST  GUN 
2CiMH  GUN 


“88: 


2  SD 

10 


Figure  3-3.  Initial  Inventory  Stock  List 


c.  Scenario  Input  Data  Sunmary  (Figure  3-4).  This  output  "echoes"  much 
of  the  scenario  input  data.  It  includes  a  table  showing,  on  a  daily  basis, 
the  cumulative  aircraft  deployed,  the  program  flying  hours,  the  minimum 
aircraft  availability  objective,  the  aircraft  lost  (attrition),  and  the 
cumulative  aircraft  lost.  This  table  has  sufficient  information  to  enable 
the  model  user  to  convert  a  PARCOM-generated  aircraft  availability  into 
"number  of  aircraft  available"  and  a  "fraction  flying  hour  program  achieved" 
into  "number  of  program  hours  achieved". 


CAStrus?  number  i 

SCENARIO  INPUT  DATA  SUMMARY 

uSI  OFFSET^  *0  OAfS  0CS1RC0  CONVERGCCC:  .UUq  MAX  ITERATIONS:  2  £$S£NT | ALI Ty:  9 

MAX  FLY  HRS/ACFl/OAV:  10*0  AOO-ON  COS?  LlMl-  9300*  NO  SU8  CUM  ROM?  COST  CALC  EA  I  DAYS 
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Figure  3-4.  Scenario  Input  Data  Sunmary 
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d.  Current  Inventory  Cost  Report  (Figure  3-5).  The  amount  shown  is  the 
dollar  value  of  the  total  initial  inventory  of  parts  processed.  Note  that 
this  amount  excludes  parts  in  the  data  base  which  are  not  processed 
(because  of  zero  failure  rate  or  inappropriate  essentiality  code).  For 
parts  processed,  valuation  is  determined  by  accumulating  the  product  of 
initial  inventory  and  part  unit  cost. 


CASE-  TEST  *)UKEER  1 


COST  OF  CUrtREM  INVENTOPtr  1005CQ. 


Figure  3-5.  Current  Inventory  Cost  Report 


e.  Cost-ordered  Parts  List  (Figure  3-6).  It  shows  part  number,  part 
description,  and  part  unit  cost  ranked  in  decreasing  order  of  part  unit 
cost.  RANK  denotes  the  rank  order  (over  all  processed  part  types).  PART 
denotes  the  associated  part  number  (as  defined  in  paragraph  3-3a). 


CASE=TCST  NUNBER  ! 
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Figure  3-6.  Cost-ordered  Parts  List 
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f.  Unconstrained  Dollar  Total  Requirements  Total  Cost  List  (Figure 
3-7).  The  output  shows  the  total  cost  of  the  least-cost  total  requirements 
unconstrained  cost  solution  (based  on  zero  initial  inventory)  for  each  of 
the  three  policies  ("no  substitution,"  “full  substitution,"  and  "NMCS  = 

0.")  Costs  are  computed  by  cumulating  the  product  of  part  unit  cost  and 
total  units  (of  part)  required. 


CASE-TEST  NUMBER  1 
TOTALIINIT  S  TK  -  l!  I  COST  OF  POLICIES 
POLICy  TOT  COST 


NO  SUB 
FULL  SUB 
NM  C  S  -  0 


1 12C30. 
109500. 
132030. 


Figure  3-7.  Unconstrained  Dollar  Total  Requirements  Total  Cost  List 


g.  Unconstrained  Dollar  Residual  Requirements  Total  Cost  List  (Figure 
3-8).  The  output  shows  the  total  cost  of  the  least-cost  residual  require¬ 
ments  unconstrained  cost  solution  (add-on  based  on  input  initial  inventory) 
for  each  of  the  three  policies. 


CASE  =  TEST  NUMBER  1 


r.CsI  Du  AL  1INI  T  STK=CURR  S  TK  )  COST  OF  POLICIES 


POLICY 


TOT  COST 


NO  SUB 
FULL  SUB 
NM  CS  -3 


4o3dI 

31530. 


Figure  3-8.  Unconstrained  Dollar  Residual  Requirements 

Total  Cost  List 


1  * 
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h.  Constrained  Dollar  Cost  Limit  Sunmary  (Figure  3-9).  The  output  is  a 
printed  summary  of  cost  data  required  for  the  constrained  cost  case  proces¬ 
sing.  The  first  such  item  is  the  "cost  constraint  of  added  buy,"  which  is 
just  the  input  cost  limit  (in  dollars)  of  the  constrained  cost  spares  buy. 
The  second  item  is  "cost  of  current  required  inventory"  which  is  just  the 
total  value,  over  processed  part  types,  of  initial  inventory  less  than  or 
equal  to  the  "NMCS  =  0"  requirement.  In  computing  this  item,  supply  (in¬ 
ventory)  in  excess  of  total  expected  net  demand  (the  "NMCS  =  0"  require¬ 
ment)  is  ignored.  Also  input  part  types  not  selected  for  processing  (be¬ 
cause  of  zero  failure  rate  or  inappropriate  essentiality  code)  are  ignored. 
The  third  item  is  "total  cost  of  current  inventory  plus  added  buy,"  which 
is  just  the  sum  of  the  input  cost  limit  and  the  total  value,  over  processed 
part  types,  of  all  initial  inventory.  Part  types  not  selected  for  pro¬ 
cessing  are  ignored  in  this  calculation.  This  item  is  used  as  the  cost 
limit  for  the  constrained  cost  total  requirements  case  (zero  initial 
inventory). 


NO  SUBS  T 

COST  CONSTRAINT  OF  ADDED  BUY  =  4300. 

COST  OF  CURRENT  REQUIRED  INVENTORY =  lOOSOO. 

TOTAL  JCURR  INV+AOOED  BUYJ  COST-  1C4830. 


Figure  3-9.  Constrained  Dollar  Cost  Limit  Summary 


i.  Unconstrained  Dollar  Total  Requirements  Parts  List  (Figure  3-10). 

The  output  shows  the  composition  of  the  total  unconstrained  cost  require¬ 
ment  solution  mixes  (zero  initial  inventory)  for  each  policy.  Parts  re¬ 
quirements  are  listed  in  order  of  decreasing  part  unit  cost  (most  expensive 
part  is  first).  For  each  part  and  policy  is  listed: 

(1)  The  number  of  units  of  that  part  required  to  achieve  the  case 
objective  under  the  indicated  policy.  A  zero  initial  inventory  is  assumed 
in  the  "total  requirements"  case. 

(2)  The  cost  of  the  requirement  computed  in  (1),  computed  as  the 
product  of  units  required  and  part  unit  cost. 

(3)  The  percent  of  the  overall  (i.e.,  overall  parts)  requirement 
represented  by  the  requirement  for  the  part  type. 
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Figure  3-10.  Unconstrained  Dollar  Total  Requirements  Parts  List 


j.  Unconstrained  Dollar  Residual  Requirements  Parts  List  (Figure  3-11). 

The  output  shows  the  composition  of  the  residual  unconstrained  cost 
requirement  solution  mixes  (based  on  input  initial  inventory)  for  each 
policy.  Format  is  virtually  identical  to  that  of  the  total  requirements 
list,  i.e.,  parts  are  listed  in  decreasing  cost  order  and  add-on  units 
required,  cost  of  add-on  requirement,  and  associated  percent  of  overall 
requirement  are  listed  for  each  part  and  policy. 
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Figure  3-11.  Unconstrained  Dollar  Residual  Requirements  Parts  List 
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k.  Unconstrained  Dollar  Total  Requirements  Force  Capability  List 
(Figure  3-12).  The  output  shows,  as  discussed  below,  expected  achievable 
daily  aircraft  availability,  the  "driving"  factor  in  determination  of 
availability  objective,  and  flying  hours  per  available  aircraft  per  day  for 
the  "full  substitution"  and  "no  substitution"  policies,  assuming  that  the 
computed  "unconstrained  dollar  total  requirement"  (listed  in  paragraph  i 
above)  is  stocked  and  available  on  day  1. 
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Figure  3-12.  Unconstrained  Dollar  Total  Requirements 
Force  Capability  List 


(1)  Aircraft  Availability.  Aircraft  availability,  as  applied  in 
PARCOM,  is  defined  as  the  fraction  of  surviving  aircraft  which  are  not  in 
NMCS  status.  The  minimum  aircraft  availability  required  on  each  day  in 
order  to  meet  the  case  objective  is  shown  under  the  REQ  AVAIL  heading.  The 
required  availability  must  equal  the  larger  of  the  availability  reflected 
in  the  daily  flying  hour  program  and  that  specified  by  the  input  avail¬ 
ability  constraints.  An  initial  aircraft  availability  of  1.00  is  assumed. 

(2)  Availability  Source.  The  "driving"  source  of  the  daily  avail¬ 
ability  requirement  is  listed  under  the  AVAIL  SOURCE  heading.  FLYING  HR 
PROGRAM  denotes  the  daily  flying  hour  program  while  AVAIL  CONSTRAIN  denotes 
an  input  availability  constraint.  In  the  AVAIL  column  immediately  to  the 
right  of  the  AVAIL  SOURCE  entries  are  the  daily  input  availability  con¬ 
straints  input  by  the  user.  When  the  AVAIL  SOURCE  is  AVAIL  CONSTRAIN, 
these  availabilities  should  be  identical  to  corresponding  entries  in  the 
REQ  AVAIL  column. 
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(3)  Flying  Hours  per  (Available)  Aircraft  per  Day.  These  entries  are 
computed  by  dividing  the  number  of  program  flying  hours  for  the  day  by  the 
number  of  available  aircraft  on  that  day.  The  number  of  available  aircraft 
is  just  the  product  of  the  tabulated  aircraft  availability  and  the  number 
of  surviving  aircraft. 

(4)  Averages  Over  Time.  After  all  daily  status  figures  are  listed, 
PARCOM  prints  achieved  aircraft  availability,  minimum  required  availability, 
and  achieved  flying  hours  per  aircraft  per  day.  These  are  all  weighted 
averages  over  time.  In  calculating  the  weighted  averages,  each  daily  avail¬ 
ability  entry  is  weighted  by  the  number  of  surviving  aircraft  on  that  day, 
and  each  daily  "flying  hour  per  aircraft  per  day"  entry  is  weighted  by  the 
number  of  available  aircraft  on  that  day. 

1.  Unconstrained  Dollar  Residual  Requirements  Force  Capability  List 
(Figure  3-13).  The  output  is  analogous  to  the  comparable  list  for  total 
requirements  (paragraph  k  above),  i.e.,  it  shows,  for  each  day,  expected 
aircraft  availability,  required  availability  (and  source),  and  flying  hours 
per  aircraft  per  day  under  the  two-part  replacement  policies,  assuming  that 
the  computed  residual  unconstrained  cost  requirement  (listed  in  j  above)  is 
stocked  (in  addition  to  input  initial  inventory)  and  available. 
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Figure  3-13.  Unconstrained  Dollar  Residual  Requirements 
Force  Capability  List 
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m.  Selected  Items  Cumulative  Stock  Requirement  List  (Figure  3-14).  The 
output  consists  of  total  (zero  initial  inventory)  unconstrained  cost  re¬ 
quirements  for  each  of  up  to  five  selected  part  types  for  a  truncated 
scenario  of  length  N  days,  where  N  =  1,  2,  ...  through  the  last  day  of  the 
base  case  scenario.  Requirements  are  shown  for  each  of  the  three  policies. 
Each  row  of  output  corresponds  to  unconstrained  cost  total  requirements  for 
a  "war"  of  length  N  as  noted  in  the  leftmost  column.  Excluding  that  column, 
each  group  of  three  consecutive  columns  gives  requirements,  by  policy,  for 
the  part  identified,  by  description  and  NSN,  in  the  super-heading  of  each 
three-column  set.  The  selected  parts  are  specified  by  user  input  in  Record 
Set  9  of  the  Scenario  Input  Oata  Base.  The  tabulated  requirements  repre¬ 
sent  an  extract  from  the  requirements  computed  over  the  full  part  data  base 
(not  over  just  the  part  types  shown).  The  purpose  of  the  output  list  is  to 
allow  the  user  to  examine  the  changing  demand,  over  time,  for  certain  key 
parts  under  the  various  policies. 
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Figure  3-14.  Selected  Items  Cumulative  Stock  Requirement  List 


n.  Total  Requirement  Cumulative  Cost  List  (Figure  3-15).  The  output 
consists  of  the  total  cost  (all  parts)  of  the  total  unconstrained  cost  re¬ 
quirements  solution  (zero  initial  stock)  for  each  policy  applied  in  a 
truncated  scenario  consisting  of  the  first  N  days  of  the  base  scenario, 
where  N  =  1,  2,  ...  through  the  last  day  of  the  base  scenario.  The  left¬ 
most  column  shows  the  last  day  of  the  truncated  scenario  while  the  three 
entries  on  the  same  line  show  the  total  requirement  cost  by  policy.  As 
before,  total  cost  consists  of  the  product  of  units  required  and  part  unit 
cost,  summarized  over  all  part  types  processed.  The  costs  on  the  last  line 
(day)  of  the  output  list  should  be  the  same  as  those  in  the  Unconstrained 
Dollar  Total  Requirements  Cost  List  (paragraph  f  above).  Another  inter¬ 
pretation  of  this  output  is  that  it  gives,  for  each  policy,  the  expected 
cost  for  total  requirements  required  to  sustain  the  flying  hour/availabil¬ 
ity  objective  through  any  specified  day  of  the  scenario. 
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Figure  3-15.  Total  Requirement  Cumulative  Cost  List 
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o.  Cumulative  Residual  Stock  Requirement  Cost  List  (Figure  3-16). 

Output  consists  of  total  costs  (all  parts)  of  the  residual  unconstrained 
cost  requirements  solution  (add-on  based  on  initial  inventory)  for  each 
policy  applied  in  a  truncated  scenario  of  N  days,  N  =  1,  2,  ...  through  the 
last  day  of  the  base  scenario.  Total  costs  are  computed  in  the  same  way  as 
in  paragraph  n;  however,  these  are  add-on  costs.  Initial  inventory  is  not 
costed  here,  but  is  treated  as  a  "sunk"  asset.  The  costs  on  the  last  line 
(day)  of  the  output  list  should  be  the  same  as  those  in  the  Unconstrained 
Dollar  Residual  Requirements  Cost  List  (paragraph  g  above).  Another  inter¬ 
pretation  of  this  output  is  that  it  gives,  for  each  policy,  the  expected 
cost,  for  residual  (add-on)  requirements,  required  to  sustain  the  flying 
hour/avai lability  objective  through  any  specified  day  of  the  scenario. 
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Figure  3-16.  Residual  Requirement  Cumulative  Cost  List 
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p.  Constrained  Dollar  Total  Requirements  Parts  List  (Figure  3-17).  The 

output  is  only  printed  if  the  sum  of  the  total  cost  of  initial  inventory 
and  the  input  cost  limit  is  less  than  the  total  cost  of  the  unconstrained 
cost  requirements  solution  for  a  "no  substitution"  policy.  The  first  sum 
was  noted  at  the  end  of  the  Constrained  Dollar  Cost  Limit  Summary  (para¬ 
graph  h  above).  If  the  cost  of  the  unconstrained  cost  solution  is  the 
smaller  of  the  two,  then  the  unconstrained  cost  part  mix  is  also  the 
solution  of  the  constrained  cost  total  requirements  problem.  If  a  solution 
mix  is  printed,  it  consists  of  total  requirements  for  each  part  (zero 
initial  inventory),  using  a  "no  substitution"  policy,  based  on  a  computed 
cost  limit  equal  to  the  sum  of  the  input  cost  limit  and  the  "cost  of  cur¬ 
rent  inventory"  as  noted  above  and  in  subparagraph  h.  The  computed  cost 
limit  is  also  printed  in  the  table  header,  viz.,  — (=  XXXXX)  AVAIL  FOR 
REALLOCATION.  The  XXXXX  denotes  the  cost  limit  for  the  case.  The  output 
format  is  similar  to  that  of  the  Unconstrained  Dollar  Total  Requirements 
List  (subparagraph  i)  except  that  the  only  entries  are  under  the  "no  sub¬ 
stitution"  policy  heading.  The  parts  are  listed  in  order  of  decreasing 
unit  cost.  Each  processed  part  NSN  and  description  are  listed,  along  with 
the  solution  amount  required,  the  cost  of  that  amount,  and  the  percent  of 
overall  cost  (all  parts)  repre-sented  by  that  amount.  The  solution  repre¬ 
sented  tends  toward  the  maximally  productive  (in  terms  of  cumulative  flying 
hours  achieved)  constrained  cost  "no  substitution"  total  parts  mix,  based 
on  zero  initial  inventory,  which  is  "priced"  at  the  computed  cost  limit. 
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Figure  3-17.  Constrained  Dollar  Total  Requirements  Parts  List 
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q.  Constrained  Dollar  Residual  Requirements  Parts  List  (Figure  3-18). 

The  output  format  is  analogous  to  Figure  3-17.  However,  Figure  3-18  shows 
the  composition  of  the  "maximally  productive"  add-on  "no  substitution"  parts 
mix,  which  is  "priced"  at  the  input  cost  limit.  The  add-on  is  relative  to 
the  input-specified  initial  inventory.  As  before,  the  NSN  and  description 
of  each  processed  part  are  listed,  along  with  the  amount,  cost,  and  percent 
of  total  requirements.  The  table  header  CURR  STK  =  INIT  STK,  ONLY  COST  OF 
ADDED  BUY  (=  XXXX)  IS  AVAIL  FOR  REALLOCATION  prints  the  input  cost  limit 
(denoted  by  XXXX  above).  As  with  all  residual  requirement  lists,  the  solu¬ 
tion  mix  shown  does  not  include  parts  in  initial  inventory.  Only  the  add¬ 
on  portion  is  displayed  and  costed. 
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Figure  3-18.  Constrained  Dollar  Residual  Requirements  Parts  List 


r.  Constrained  Dollar  Total  Requirements  Force  Capability  List  (Figure 
3-19).  The  output  shows,  under  a  "no  substitution"  policy  and  for  an  ini¬ 
tial  spare  pool  stock  equal  to  the  previously  computed  (paragraph  p  above) 
con-strained  cost  total  stock  requirement: 

(1)  Expected  achievable  daily  and  average  aircraft  availability. 

(2)  The  daily  and  average  minimum  aircraft  availability  required  to 
meet  the  base  case  objective. 

(3)  Expected  achievable  daily  and  average  fraction  program  flying 
hours  flown. 

(4)  Expected  daily  and  average  achievable  flying  hours  per  available 
aircraft  per  day. 
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In  addition,  since  the  achieved  flying  hours  are  computed  by  means  of  a 
convergence  process,  information  on  the  closeness  of  the  convergence  is 
printed.  The  header  TOTAL  FLY  HRS  CONVERGED  TO  WITHIN  X.XX  PERCENT  shows 
the  closeness,  denoted  above  by  X.XX,  as  a  percent  of  the  total  program 
flying  hours.  The  value  of  X.XX  is  determined  by  inputs  CONVF  and  LIMIT  in 
record  sets  1  and  3,  respectively,  of  the  Scenario  Input  Data  Base.  The 
percent  closeness  achieved  will  be  less  than  100*C0NVF  unless  LIMIT  iter¬ 
ations  were  done  without  attaining  sufficient  closeness.  A  smaller  close¬ 
ness  can  be  achieved  by  reducing  the  input  value  of  CONVF  and/or  increasing 
the  input  value  of  LIMIT.  The  value  of  the  computed  cost  limit  used  in  the 
case  is  printed  in  the  same  header  format  as  in  the  Constrained  Dollar  Total 
Requirements  List. 
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Figure  3-19.  Constrained  Dollar  Total  Requirements 
Force  Capability  List 


s.  Force  Capability  List  for  Constrained  Dollar  Residual  Requirements 
(Figure  3-20).  The  output  shows,  under  a  "no  substitution"  policy,  the 
same  information  as  in  paragraph  r  above,  but  for  an  initial  spare  pool 
stock  equal  to  the  sum  of  the  previously  computed  (paragraph  q  above)  con¬ 
strained  cost  residual  stock  requirement  and  the  original  initial  stock. 

As  in  the  immediately  preceding  force  capability  list,  information  on  the 
closeness  of  convergence  of  achieved  flying  hours  is  printed  in  the  table 
header. 
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Figure  3-20.  Constrained  Dollar  Residual  Requirements 
Force  Capability  List 
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